feat: Blueapi policy#304
Conversation
Alexj9837
force-pushed
the
blueapi_policy
branch
4 times, most recently
from
55a4d89 to
22857f8
Compare
|
I don't think we're ever going to have task data available in OPA. Most of these task checks will have to be on the blueapi side. |
tpoliaw
left a comment
tpoliaw
left a comment
There was a problem hiding this comment.
Might need a rebase, this is wiping out the tiled service account change
|
this contains policies related to DiamondLightSource/blueapi#1541, both should be handled together |
Alexj9837
force-pushed
the
blueapi_policy
branch
from
2ff4504 to
6a68c7c
Compare
NeilSmithDLS
left a comment
NeilSmithDLS
left a comment
There was a problem hiding this comment.
mainly questions... not sure anything needs to change
| post_task if { | ||
| session.write_to_beamline_visit | ||
| } | ||
|
|
There was a problem hiding this comment.
IS it right that admins should not be able to post tasks?
| diamond_data := { | ||
| "subjects": { | ||
| "alice": { | ||
| "permissions": [], |
There was a problem hiding this comment.
what do these permissions represent? Where is the data retrieved in the real system?
| "proposal_number": 1, | ||
| "visit_number": 2, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
In this data what is the difference between a "session" and a "visit"? Within DAQ these words are usually synonymous but within this data the sessions have an "id" (11, 12) and a different visit_number.
I assume that the "session" represents the internal session_id from within ISPyB which is currently in the data bundle within the authz.diamond.ac.uk OPA PoC? In which case, for information this data structure is changing as part of the OPA productionisation work that my team are doing
3 participants
Jira ticket
Adds Rego policy for blueapi task submission and querying.
task ownership (delete,query,about) by comparing "user" in the meta against fedid